|
I_01 - Unnamed Association |
|---|---|
| This rule ensures that an association has a name. | |
|
I_02 - Naming conflicts check 2 |
|---|---|
| NOTE: This constraint is replaced by "I_19 - Name conflict" and thus disabled by default. This rule checks that an element doesn't contain a naming conflict between different types of elements in the same package. | |
|
I_03 - Logical Actor Realization |
|---|---|
| This rule Ensures that Logical Actor always realizes a Sytem Actor. | |
|
I_04 - System Actor Realizationtion |
|---|---|
| This rule Ensures that System Actor always realizes an Entity (that is aslo an Operational Actor). | |
|
I_05 - Operational Entity Realization |
|---|---|
| This rule ensures that Operational Entities Realizations always have Actor or System instances as source and Operational Entity instances as target. | |
|
I_06 - Physical Actor Realization |
|---|---|
| This rule Ensures that Physical Actor always realizes a Logical Actor. | |
|
I_07 - Diagram Naming conflicts check |
|---|---|
| This rule checks that a diagram doesn't contain a naming conflict. | |
|
I_08 - Naming conflicts check 1 |
|---|---|
| NOTE: This constraint is replaced by "I_19 - Name conflict" and thus disabled by default. This rule checks that an element doesn't contain a naming conflict. Usually this means that two elements in the same container cannot have the same name, e.g. one cannot create two classes in a package and assign them identical names. Below we list the special cases: ExchangeItems Two exchange items that share a common container have conflicting names if both have the same name, and the order, number and type of their ExchangeItemElements is identical. | |
|
I_09 - Exchanges Naming conflicts check 1 |
|---|---|
| This rule ensures that an element doesn't contain a naming conflict. This rule only applies to exchanges (Component Exchanges, Physical Links and Functional Exchanges) which have the same source (Component / function), the same target (Component / function) and the same name. | |
|
I_10 - Unnamed Element |
|---|---|
| This rule checks that an element has a name and does not contain a naming conflict. This rule does not check ExchangeItemAllocations and DataValues. | |
|
I_11 - Requirement ID check |
|---|---|
| This rule checks that all Requirements have a unique ID attribute. | |
|
I_12 - Function Realization |
|---|---|
| This test checks the realization consistency between functions. | |
|
I_13 - Functional chain involvement check 2 |
|---|---|
| This rule checks that a Functional Chain Involvement involver is its owning Functional Chain. | |
|
I_14 - Functional Exchange Realization |
|---|---|
| This rule checks the realization consistency between functional exchanges. | |
|
I_15 - Component Exchange Functional Exchange Realization |
|---|---|
| This rule checks the realization consistency between Functional Exchanges and Component Exchange. | |
|
I_16 - Several Implementation/Use of the same interface by a component Check |
|---|---|
| This rule allows to ensure that a component cannot implement the same interface several times or use the same interface several times. | |
|
I_17 - Contexts minimal content check |
|---|---|
| This rule checks that context packages contain at least one component (the root component) of the correct level. | |
|
I_19 - Name conflict |
|---|---|
| This rule Finds name conflicts. NOTE: This constraint include all Naming conflict detection and it is enabled by default. This rule checks that an capella element doesn't contain any naming conflict. Usually this means that two elements in the same container cannot have the same name | |
|
I_20 - ComponentExchange port orientation |
|---|---|
| This rule cheks that source and target port orientations of a ComponentExchange are consistent, i.e. - A source port cannot have orientation'IN' - A target port cannot have orientation 'OUT' In Case the ComponentExchange is of kind DELEGATION - "source port/target Port" can only have orientation 'IN/IN' or 'OUT/OUT' | |
|
I_21 - Unique Model Element IDs |
|---|---|
| This rule checks that all capella elements have a unique ID. | |
|
I_22 - HyperLink to capella element or diagram name check |
|---|---|
| This rule ensures that hyperLinks to capella elements or diagrams names are up to date. | |
|
I_23 - HyperLink to capella element or diagram existance check |
|---|---|
| This rule ensures that hyperLinks to non existing capella element or diagram are removed from the description. | |
|
I_24 - Operational Analysis Realization |
|---|---|
| This rule ensures that Operational Analysis Realization links targeting Operational Analysis instances have System Analysis instances as source. | |
|
I_25 - Description is well formed XML |
|---|---|
| This rule checks whether the description of a model element is well formed XML. | |
|
I_26 - Equivalent Trace Elements |
|---|---|
| Checks that there are no equivalent trace elements. Two trace elements are equivalent if they have identical types and identical source and target elements. | |
|
I_27 - Functional chain involvement check 3 |
|---|---|
| This rule checks that a Functional Chain Involvement has a valid next and/or previous involvement (not empty) | |
|
I_28 - Functional chain involvement check 4 |
|---|---|
| This rule checks that a Functional Chain Involvement has a valid next and/or previous involvement (contained by the same functional chain) | |
|
I_29 - Physical path involvement check 1 |
|---|---|
| This rule checks that a Physical Path Involvement has a valid next and/or previous involvement (not empty) | |
|
I_30 - Physical path involvement check 2 |
|---|---|
| This rule checks that a Physical Path Involvement has a valid next and/or previous involvement (contained by the same physical path) | |
|
I_31 - check Null Part |
|---|---|
| This rule checks that a Component Exchange / Physical Link End doesn't have a part Null. | |
|
I_32 - Check Component Exchange / Physical Link Ends in SingletonComponents mode |
|---|---|
| This rule ensures that Component Exchange / Physical Link Ends are restricted to reusable mode defined in Key Value"projectApproach". | |
|
I_33 - Check Reused Parts in SingletonComponents mode |
|---|---|
| This rule checks that reused parts are not used when the project approach is in default mode (not in reusable mode). | |
|
I_34 - Inter-model inconsistency Detection |
|---|---|
| This rule detects inter-model inconsistencies (dependency violations and inter-model cycles). | |
|
I_35 - Related functional exchanges must have identical names |
|---|---|
| This rule checks that Functional Exchanges connected to the same source and/or target port have identical names. | |
|
I_37 - Validate referential constraints during move |
|---|---|
| This rule detects forbidden references when elements are moved via the Move Staging View. For example, a Component in a Capella Project cannot allocate a Function from a Library. Moving a Project Function to a Library may introduce such a forbidden reference. If such a reference is detected, the move operation is aborted. | |
|
I_38 - Validate referential constraints |
|---|---|
| This rule detects forbidden references. For example, a Logical Architecture Class cannot extend a Physical Architecture Class. | |
|
I_39 - Validate inter-model references |
|---|---|
| This rule live validation rule detects illegal inter-model references: An element in model A can only reference an element in model B if A has declared a "Library Reference" to B. | |